Network service providers are facing a major migration challenge, as the telephony networks currently deployed using TDM digital switches need to be redesigned to use voice over internet protocol (VoIP). Emerging standards such as the European Telecommunication Standards Institute (ETSI) 3rd Generation Partnership (3GPP) IMS also change the way network services may be designed.
In conventional telephone networks employing TDM, a major issue faced by complex telecom services is the so-called “tromboning”, which means that a switch which implements a specific service and which is used to set up a call also processes the voice bearer channels when the call has already been set up.
In a large network, a call from a user located in a city A to another user also in the city A may need to be processed by a centralized switch located in a city B. If the distance between these two cities is large, then the voice path is long enough to introduce perceptible delays, echoes, and require additional and expensive echo cancellers.
The widely used signaling system #7 (SS7) does not solve the problem even if the transport networks are separate for signaling and voice bearers. In fact, although the transport network of the signaling and voice are indeed separate, the SS7 integrated services digital network user part (ISUP) signaling and voice bearers are still processed by each switch. It is not feasible to build centralized service switches processing only SS7 ISUP without also implementing a TDM switching matrix for the voice bearers. Therefore, TDM centralized service switches continue to cause tromboning issues even in TDM networks using SS7 signaling.
The technology called intelligent network (IN) can be used in order to partially solve this problem. This technology uses an abstract call model, and lets an external application interact with a remote TDM switch using control primitives acting on the abstract call model. The intelligent network application part (INAP) protocol standardized by the International Telecommunications Union (ITU) (ITU-T SG 11, recommendation Q1224 approved in 1997) is the most widely used protocol enabling an external application to interact with remote TDM switches using a call processing logic that can be modeled according to the state machine defined by ITU Q1224. The ITU has also defined IN capability set (CS) call models (ITU-T SG 11 Q1244 defines CS4), which let INAP applications control voice over IP (VoIP) calls.
FIG. 1 represents a simplified block diagram of a prior art TDM IN 100 solution. In FIG. 1 there are two telephones 101 that are connected to each other via a service switching point (SSP) 103 also known as a service switching function (SSF). The SSP 103 is further connected to a service control point (SCP) 105 also known as a service control function (SCF). In FIG. 1 the phones 101 are physically located in cities A and C, whereas the SSP 103 is located in the city B. Even if the phones 101 were located in the same city, for instance in the city A, all calls, i.e. signaling and media, would have to be processed through the city B where the SSP 103 is located. The distance between A, B and C can be hundreds or even thousands of kilometers creating a potential tromboning problem, and possibly inducing echo. For this reason the SSP 103 is often collocated with local telephone exchanges requiring many points of presence for such SSP function and inducing substantial costs.
The SSP 103 acts as a trigger point for further services to be invoked during a call. The SSP 103 may invoke a query to the SCP 105 to wait for instructions on how to proceed. The SCP 105 contains service logic which implements the behavior described by the operator. This enables service providers to deploy the application logic centrally, while only SSPs are distributed. The signaling protocol used between the SSP 103 and the SCP 105 is INAP and is based on an abstract call model which represents the capabilities of the SSP 103.
The SSP and SCP functions can also be collocated, leading to the so-called “service node” deployment model. In this case there is no longer a requirement for standardized call model. However, this induces even higher costs as the SSP function needs to be distributed because of tromboning issues and therefore, in this case also the application needs to be deployed over multiple Points of Presence (POPs).
By contrast to TDM technology, VoIP technology separates the media transport plane and the call & media control plane. A VoIP service switch can interact with media streams without processing the IP packets containing the signaling at all.
For instance, in FIG. 1, if the phones 101 are communicating with each other by use of VoIP, then the calls are set up via the SSP 103 but once the calls are set up, the IP packets transporting the media stream can be routed to the destination directly without a need to route the packets via the SSP 103 any longer. The tromboning problem no longer exists in a properly designed VoIP network. Because there is no tromboning, the SSP function can now be centralized and because it can be centralized it can also be collocated with the application logic itself (SCP). With both SSP and SCP collocated, there is no longer a need for a standardized call model supporting communication between them.
Recognizing this major improvement, the ETSI 3rd Generation Partnership Project (3GPP) defined internet protocol multimedia subsystem (IMS) which is a new telecommunications service architecture optimized for VoIP technology.
FIG. 2 shows a simplified block diagram of an IMS network 200. An IP network 201 is connected to a call session control function (CSCF) block 203. The CSCF block 203 further comprises serving CSCF (S-CSCF) 205, interrogating CSCF (I-CSCF) 207 and proxy CSCF (P-CSCF) 209. The CSCF block 203 is connected to application servers (ASs) 213. The IMS calls are processed by one or several ASs under control of the S-CSCF 205.
The CSCF block 203 is further connected to home subscriber server (HSS) 211. It contains the subscriber-related information, performs authentication and authorization of the user, and can provide information of the physical location of the user. The CSCF block 203 is further connected to a media resource function (MRF) 215 and a gateway 217, which interfaces with a circuit switched public switched telephone network (PSTN) or public land mobile network (PLMN) 219. The MRF 215 provides a source of media in the home network and it is, for instance used for playing announcements, real-time transcoding of multimedia data, text-to-speech conversation and speech recognition.
The use of VoIP by the IMS network 200 has an important consequence. While TDM networks required a standardized call model in order to allow applications to efficiently interact with the communications network, the ASs 213 have access to the call signaling directly, and therefore no call model is required. This gives much more flexibility to application designers, reduces the complexity of the network, mainly by reducing the level of interactions between components, and makes it possible to introduce applications not previously allowed by the call models standardized for TDM networks.
For instance the IMS network 200 allows support for applications in a roaming environment for cellular phones. In TDM INs 100 most services, e.g. a short numbering plan for a corporation, are lost when roaming outside of the home network, because routing outgoing calls to the home network would create a tromboning problem, and because INAP links are not so frequently allowed among roaming networks. In an IMS network 200, on the contrary, the signaling of all calls placed by an end user in a roaming situation is routed to the home network, and therefore most services working in the home environment will work in a roaming situation.
Many service providers are now convinced that the advantages brought by VoIP and the IMS architecture justify a migration of TDM networks to VoIP and IMS. However, such a migration takes a long time, and for a long time TDM networks such as mobile GSM networks and IMS networks 200 will have to coexist. It is tempting for TDM service providers to start developing all new applications in an IMS mode, using IMS ASs 213, and stop developing IN applications in current TDM networks. However, most IMS devices will have to work in dual mode initially, and therefore the same application logic needs to be available while working in IMS mode or working in TDM mode.
Developing applications for the two networks would require to either develop them twice, as IMS AS applications and as IN applications, or would require introducing an IMS AS implementing an IN call model and develop the application in IN mode only.
The latter approach, using an IN call model for VoIP networks, has been proposed by multiple standard bodies and resulted in concepts and products such as IN CS4, JAIN or PARLAY. Although this approach does have the merit of allowing a single application to run over a TDM or a VoIP network, it does have significant drawbacks.
It proposes to continue using the standardized call model of the IN 100, and therefore has some limitations. All applications cannot be developed using the IN call models. It introduces a complexity not required by most native IMS applications that could be implemented directly over an IMS AS 213, and perhaps using other call models or application programming interfaces (APIs) more suited to the application. It does not enable building applications controlling both TDM and IP legs in a transparent manner: applications need to control separately TDM to TDM calls, and IP to IP calls. TDM to IP calls need to be processed twice: once by the TDM to TDM application logic which is responsible to route the call to a VoIP gateway, then by the VoIP to VoIP application logic. The VoIP to TDM bridge logic has to be designed by each application developer.